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transmitted to: Mail Stop Appeal Briefs - Patents, Commissioner 
for Patents, P.O. Box 1450, Alexandria, VA 22313-1450, on 



February 13,2007. 




Rosalind Q. Spiller 
Date of Signature: February 13, 2007. 

To: Mail Stop Appeal Briefs - Patents 
Commissioner for Patents 
P.O. Box 1450, Alexandria, VA 22313-1450 

Dear Sir: 

APPELLANTS' REPLY APPEAL BRIEF TO THE BOARD OF 
PATENT APPEALS AND INTERFERENCES 

This Reply Brief is being filed pursuant to 37 C.F.R. §41.41 in rebuttal to certain 
characterizations and conclusions set forth in the Examiner's Answer having a mailing date of 
December 14, 2006, for the above-designated Appeal. Thus, any Reply Brief is due by February 
14, 2007. Therefore, this Reply Brief is being timely filed. 
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ARGUMENT 

I. Rejection under 35 U.S.C. 102(b) over ERPNet (Dialog File 20, accession No. 
02821200) 

Against the claim 1 aspect of causing a reply to the communication to be produced within 
the private electronic environment in real time, the Examiner's Answer continues to cite to 
paragraphs 8 and 9 of ERPNet. Appellants submit that in ERPNet, the communication is an 
automobile order. For the convenience of the Board, Appellants quote paragraph 9 of ERPNet 
below: 

ERPNet enables customers to monitor the flow of the entire four- 
city transaction and the speed of orders being placed. Through 
Candle's Roma Systems Manager, users can see a graphical 
depiction of their order/message from front end to back end. This 
end-to-end detail provides network managers with the ability to 
isolate slowdowns caused by problems with networked 
applications. In addition, Roma System Manager provides 
facilities for workload balancing and quality of service. 

In particular, the Examiner's Answer alleges (bottom page 5 to top page 6) that paragraph 
9 discloses a reply sent back to the user in the form of a status update. However, Appellants 
submit that a reply to an automobile order might be, for example, confirmation of the order, or 
delivery or notification of delivery of the automobile ordered. What is in paragraph 9 of 
ERPNet, however, is none of those things. Rather, what is disclosed is monitoring the flow of 
the order from the front end to the back end. Visualizing the description in paragraph 9, one can 
imagine a moving icon on a map, the icon representing the order traveling back to the factory. 
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Appellants submit that monitoring front-end-to-back-end flow of the automobile order is simply 
not a reply to the order, and certainly is not a reply within the meaning of claim 1 . 

Appellants submit that claim 1 uses the term "reply" in the sense of a response to the 
communication. See the specification at, for example, page 4, line 3, and the abstract. In 
contrast, Appellants submit that ERPNet discloses observing the one-way travels of an 
automobile order, rather than replying or responding to it. 

Therefore, Appellants submit that claim 1 (and claims 29, 57 and 85) cannot be 
anticipated by ERPNet. 

Against claims 3 and 4, the Examiner's Answer alleges that ERPNet discloses using 
middleware to communicate messages. However, neither claim recites simply using middleware 
to communicate messages. Rather, claim 3 recites messaging middleware causing the ERP 
application to produce the reply while the front end application and the messaging middleware 
wait therefore, and claim 4 recites that the causing further comprises causing by the messaging 
middleware a command to be issued to the ERP application to trigger production of the reply. 
As noted above, Appellants submit that ERPNet does not disclose a reply within the meaning of 
the claims, and there certainly is no disclosure regarding messaging middleware causing a 
command to be issued to the ERP application to trigger production of the reply. In short, merely 
mentioning middleware does not disclose the particular limitations of claims 3 or 4. 

Therefore, Appellants submit that neither claim 3 nor claim 4 (nor corresponding claims 
31, 59, 87, 32, 60 and 88) can be anticipated by, or made obvious over, ERPNet. 
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Against claims 10, 15 and 23, the Examiner's Answer alleges that ERPNet discloses the 
front end can include a browser over the Internet, citing to paragraph 6. However, again, none of 
these claims recite what is alleged, except that claim 23 includes the term "browser" in the 
preamble. Rather, claim 10 recites details regarding forwarding the communication from the 
hosting server to the messaging middleware, specifying a path through particular components of 
the messaging middleware; claim 15 recites generating, forwarding and returning a token 
identifier to/from particular messaging middleware components; and claim 23 recites details 
regarding the path of the communication to the ERP application, including forwarding to 
particular components of the messaging middleware. Appellants submit that none of the 
limitations of claims 10, 15 or 23 are disclosed in the cited section of ERPNet or ERPNet 
generally. 

Therefore, Appellants submit that none of claims 10, 15 or 23 (nor related claims 38, 66, 
94, 43, 71, 99, 51, 79 or 107) can be anticipated by, or made obvious over, ERPNet. 

Against claim 1 1, the Examiner's Answer alleges that ERPNet discloses tracking the 
communication, citing paragraph 9. However, claim 1 1 does not recite tracking a 
communication. Rather, claim 1 1 recites generating, forwarding and returning a token identifier 
to/from particular messaging middleware components. Appellants submit that none of the 
limitations of claim 1 1 are disclosed in the cited section of ERPNet or ERPNet generally. 

Therefore, Appellants submit that claim 1 1 (nor related claims 39, 67 and 95) can be 
anticipated by, or made obvious over, ERPNet. 
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Against claim 14, the Examiner's Answer alleges that ERPNet discloses sending the 
communication across a firewall, citing paragraph 14. However, again claim 14 does not recite 
merely sending a communication across a firewall. Rather, claim 14 recites forwarding the 
communication between particular messaging middleware components across a firewall. 
Appellants submit there is no disclosure in ERPNet regarding the particular messaging 
components or forwarding a communication between them. 

Therefore, Appellants submit that claim 14 (nor related claims 42, 70 and 98) can be 
anticipated by, or made obvious over, ERPNet. 

II. Rejection under 35 U.S.C. 102(b) over Gralla "How the Internet Works" 

To clarify Appellant's position regarding public/private electronic environments in 
Gralla, Appellants submit one skilled in the art would understand that the transaction server has a 
public portion that is connected to the Internet, and a private portion that is connected to the 
bank. It is well known to use a firewall to separate the public and private portions in such cases 
for security of the financial institution. The order form from a user (the communication) comes 
into the public portion, but the credit inquiry (a separate communication) is sent from the private 
portion of the transaction server to the bank, which also receives the bank's response. Thus, the 
inquiry and response exist in the private electronic environment. Yes, the private portion of the 
transaction server must receive the credit card number, however, even if the number were 
forwarded through the firewall versus being sent as a new message through the firewall (Gralla is 
silent on that issue), the credit card number is only a small portion of the information received in 
the order form from the user. The claim does not recite routing a portion of a communication 
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from public to private, but routing the communication itself. Moreover, Appellants submit the 
response ("OK") from the bank is not returned to the public electronic environment. Rather, the 
transaction server simply processes the order and thanks the user. Appellants submit the order 
processing takes place in the private portion of the transaction server (the firewall protects this as 
well), and then any data needed for the order confirmation (or the confirmation itself) is sent 
back through the firewall to the public portion of the transaction server for providing the user 
with an order confirmation. 



Therefore, Appellants submit that claim 1 (and related claims 29, 57 and 85) cannot be 
anticipated by, or rendered obvious over, Gralla. 



CONCLUSION 



In conclusion, Appellants submit that the claims are not anticipated by ERPNet or Gralla, 
and that the final Office Action rejection should be reversed in all aspects argued in the Appeal 
Brief and augmented in this Reply Brief. 



Wayne F. Reinke, Esq. 
Attorney for Appellants 
Registration No. 36,650 

Dated: February 13, 2007. 
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